home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 1001 < prev    next >
Text File  |  1994-08-27  |  4KB  |  104 lines
  1. Subject: digest
  2. Date: Mon, 25 Jul 1994 11:11:43 +1000
  3. From: Warwick Allison <warwick@cs.uq.oz.au>
  4. Precedence: bulk
  5.  
  6.  
  7. Rick Flashman:
  8.  
  9. >Kevin O'Donovan:
  10. >> Click on a window border, or the window move bar (in the latter case
  11. >> remembering that a click and a drag are different, of course)
  12. >
  13. >My concern is that you are now changing "previous" behavior.
  14.  
  15. Clicking on the title bar has always topped the window.  Under X11, this is
  16. also the case.  What we are changing is that now clicks on things inside the
  17. work area now actually work, rather than just causing the window to top.
  18.  
  19. Yes, this is a change of behaviour, but it is a change to a MORE logical
  20. operation, so it is very easy for users to accept, especially since it
  21. makes their life easier.
  22.  
  23.  
  24. Evan K. Langlois wrote:
  25. >
  26. >========================================================================
  27. >Really? What about objc_edit() which can't clip to a rectangle list?
  28. >========================================================================
  29. >
  30. >Don't allow user to edit field unless entire editable field is completely
  31. >visible (gotta walk lots of rectangles, very often).
  32.  
  33. Another approach is to do the edit field as a form - ie. when editing
  34. it, use form_do just drawing the edit field.  I haven't tried this yet,
  35. but it seems feasible.  
  36.  
  37.  
  38. Michel Forget:
  39. >Warwick:
  40. >>(GEM treats focus==top, in the hope that it is far
  41. >> more efficient to update a top window, but in reality, this is not the
  42. >> case
  43. >
  44. >This is news to me; if you are updating the top window, you can use
  45. >raster copies (because your work area is not obscured by anything).  This
  46. >makes it a trivial task.  If you are not the top window, though, you have
  47. >to walk the rectangle-list and redraw all kinds of little things.
  48.  
  49. Yes, it was suprising to me too.  But it turns out you can still use raster
  50. copies on partially obscured windows.  And sometimes, the fact that some of
  51. the area to raster-copy is obscured means the raster-copy goes faster, and
  52. hence is faster.  Net gain for top windows is very little.
  53.  
  54. BTW, MasterBrowse performs terribly when scrolled while it is not the
  55. top window, redrawing stuff unnecessarily.  Interestingly, this is one
  56. program that SHOULD operate well as a background window, since it makes
  57. sense for the user to run MasterBrowse on a document file, then manipulate
  58. the application which that file documents while scrolling through the
  59. document in the MasterBrowse window.
  60.  
  61.  
  62. Evan K. Langlois wrote:
  63. >3 - All graphics in windows (including window 0 with proper wind_set)
  64. >...
  65.  
  66. IMO, applications should not use the desktop for its own.  At the very
  67. least, it should be configurable (Interface is a good example of this).
  68.  
  69. > 9 - No form_do() or other locking calls.
  70.  
  71. Alerts lock, and they *SHOULD* freeze the display until the user
  72. responds (that's why they're called alerts!)
  73.  
  74.  
  75. Waldi Ravens:
  76. >I have no problem with modal dialogs for matters that need my
  77. >full attention anyway.
  78.  
  79. Sometimes, a dialog will open that asks you a question, the answer to which
  80. requires looking elsewhere on you machine.  For example, a dialog might ask
  81. `Enter phone number to dial:', and you'd like to go get the number from an
  82. email message, or out of a database, etc.
  83.  
  84. It is difficult for the author of the application to know when this is the
  85. case, so dialogs-in-windows is much easier.
  86.  
  87.  
  88. Ken/Goemon/Gehenom/Dan Hollis:
  89. >XAES (the reworked version of WinLIB PRO) is 238,592 bytes.
  90. After all that complaning about size!  GEM++ 1.99 is only 173,884 bytes.
  91. (example.prg, which exercises most of the library compiles to 135010 bytes).
  92. And I'll be the first to admit that GEM++ isn't intended for developing
  93. small GEM applications.
  94.  
  95.  
  96.  
  97. To the scheme of top-AND-select:  Why?  Just select it.  The only
  98. reason I can imagine is that topping first means you never have to walk
  99. the rectangle list when selecting objects.  But your code must already
  100. implement that anyway (for redraws), so there's no gain.  
  101.  
  102. --
  103. Warwick
  104.